home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 14678 < prev    next >
Encoding:
Text File  |  1996-08-05  |  3.6 KB  |  100 lines
  1. Newsgroups: comp.object,comp.lang.c++,comp.lang.java
  2. Path: ERA.COM!era!spencer
  3. From: spencer@ERA.COM (Spencer Allain)
  4. Subject: Re: Java: What's the Big Deal?
  5. In-Reply-To: shang@corp.mot.com's message of Mon, 1 Apr 1996 15: 54:16 GMT
  6. Message-ID: <SPENCER.96Apr1132420@zorgon.ERA.COM>
  7. Sender: news@ERA.COM
  8. Organization: Engineering Research Associates, Vienna, VA
  9. References: <4jk4ee$7ri@newsbf02.news.aol.com>
  10.     <1996Apr1.155416.12816@schbbs.mot.com>
  11. Date: Mon, 1 Apr 1996 17:24:20 GMT
  12.  
  13. In article <1996Apr1.155416.12816@schbbs.mot.com> shang@corp.mot.com (David L. Shang) writes:
  14.  
  15.    The more a program depends on GC, the more likely it will exhaust memory;
  16.    because the storage is collected only when all its references are
  17.    no longer valid, not at the time when all its references are no longer
  18.    used. Be careful, never make a variable's lifetime unecessarily longer
  19.    than the required.
  20.  
  21. Uhh, this isn't necessarily true.  By doing your own memory management in
  22. programs where large structures are passed around (and it's abiguous as
  23. to who is responsible for their deletion) memory often stays allocated
  24. longer than it needs and you often require some type of home-grown
  25. reference counting mechanism.  Of course if you don't work on applications
  26. that deal with large structures and/or complex control flows of data then
  27. you will generally exhaust memory less often than with garbage collection
  28. since you "know" exactly when something should be deleted.  The more
  29. complex the application, it often can become the case that the use of
  30. garbage collection will _reduce_ your memory requirements, since it
  31. already has optimized the memory management that you have to kludge
  32. together when it isn't available.
  33.  
  34.    The more a language depends on GC, the more likely its application will
  35.    exhaust memory, or at the best, will make the operating system busy
  36.    to crunch the memory. GC is not always required. For example:
  37.  
  38.        class point
  39.        {
  40.           public:
  41.            float x;
  42.            float y;
  43.            float z;
  44.        };
  45.        class FaceSet
  46.        {
  47.            coordIndex point[];
  48.            ...
  49.           public:        
  50.            loadCoordIndex (char* file_name)
  51.            {
  52.                one million of points read here, and
  53.                coordIndex is created as an array of
  54.                a million of points.
  55.            };
  56.        };
  57.  
  58.    With Java's array, memory will be smashed into millions of small
  59.    pieces. Here is a brief comparison:
  60.  
  61. Java not having a contiguous array structure, has nothing to do with
  62. garbage collection in general.  Also, the C++ "array" that is
  63. being compared against, is the C-style "array" (a pointer to a
  64. contiguous block of memory);  it doesn't abstract to multidimensional
  65. arrays, which are more efficiently handled in langauges with real
  66. arrays.
  67.  
  68.            Java array            C++ array
  69.  
  70.    pieces:        1,000,000 pieces        1 piece
  71.  
  72.    expence:    1,000,000 type refs +        3,000,000 floats
  73.            1,000,000 obj refs +
  74.            1,000,000 gc overheads +
  75.            3,000,000 floats
  76.  
  77.    allocation:    1,000,001 times            1 time
  78.  
  79.    free time:    1,000,001 times            1 time
  80.  
  81.  
  82. BTW, is this really how Java does all of its arrays?  If so, this
  83. will lead to painful conclusions such as the above comparison.
  84.  
  85. Oh well, I have garbage collection, and real arrays, so I'm happy
  86. either way. :-)
  87.  
  88. -Spencer
  89.  
  90. ----------------------------------------------------------------------
  91. Spencer Allain                    E-mail:  spencer@era.com
  92. Engineering Research Associates   Phone :  (703) 734-8800 x1414
  93. 1595 Spring Hill Road             Fax   :  (703) 827-9411
  94. Vienna, VA  22182-2235
  95.  
  96. <A HREF=http://www.research.digital.com/SRC/modula-3/html/home.html>
  97.              Modula-3 Home Page DEC SRC</A>
  98. <A HREF=http://www.vlsi.polymtl.ca/m3/>Modula-3 FAQ, etc. </A>
  99. ----------------------------------------------------------------------
  100.